跳到主要内容

密钥管理

密钥生命周期管理​

密钥生命周期指密钥从创建到销毁的完整过程，包括不限于生成、存储、分发、导入、使用、恢复、更新、撤销和销毁等环节。MPC-KMS基于Key Management Interoperability Protocol Specification Version 2.1和NIST SP 800-57 Part 1 Rev 5 Section 7规范提供密钥的生命周期管理，确保密码操作安全，避免密钥泄漏。

密钥的阶段和状态​

MPC-KMS密钥的生命周期被分成四个阶段六个状态：

  • Pre Operational
    • 密钥通过创建或者导入的方式添加到系统中，状态为PreActive。
    • 根据输入信息设置密钥的加密信息、用途和其他元数据。
    • 密钥可以设置通过定时器在指定时间激活。
    • 密钥不能使用
  • Operational
    • 密钥被系统定时器自动激活或者命令方式手动激活，状态为Active。
    • 密钥只能按照创建时选择的用途来使用。
    • 密钥可以暂停或者恢复，通过IsEnabled来标记。
  • Post Operational
    • 密钥被系统定时器自动撤销或者命令方式手动撤销。
    • 撤销包括普通撤销和泄漏撤销，分别状态为Deactived和Compromised。系统会记录密钥撤销的详情。
    • 密钥一旦撤销，将无法被重新激活。撤销后的密钥存在使用限制，无法用于执行生成新加密的材料的操作，包括加密、签名、封装等
    • 密钥可以暂停或者恢复，通过IsEnabled来标记。
  • Destroyed
    • 密钥被标记为废弃，根据销毁前的状态的不同最终状态也有不同。
    • 密钥无法进行任何密码操作，数据仍然保留在系统中作为后续审计用。

密钥状态迁移​

密钥当前所处状态、操作类型会产生不同的状态变迁。MPC-KMS会记录状态变迁事件信息，包括操作时间和操作原因（部分）：

  1. 执行Create操作创建密钥，包括激活标记、激活日期、去激活日期。
    • 如果激活标记未设置或者设置为立即激活，密钥状态设置为Active。
    • 如果激活标记设置手动激活，密钥状态为PreActive。
    • 如果激活标记为定时激活，但是激活日期等于当前日期，等同于立即激活，密钥状态设置为Active。
    • 如果激活标记为定时激活，但是激活日期大于当前日期，密钥状态设置为PreActive。
    • 去激活日期>激活日期>=当前日期。
  2. 执行Destroy操作，密钥状态从PreActive变更为Destroy。
  3. 执行Compromise操作，密钥状态从PreActive变更为Compromised。
  4. 下面这些操作，密钥状态从PreActive变更为Active：
    • 到达设置的激活日期，系统自动激活。
    • 手动执行Active操作。
  5. 执行Compromise操作，密钥状态从Active变更为Compromised。
  6. 下面这些操作，密钥状态从Active变更为Deactived：
    • 到达去激活日期，系统自动去激活。
    • 手动执行Revoke操作。
  7. 执行Destroy操作，密钥状态从Deactived变更为Destroy。
  8. 执行Compromise操作，密钥状态从Active变更为Compromised。
  9. 执行Destroy操作，密钥状态从Compromised变更为Destroyed Compromised。
  10. 执行Compromise操作，密钥状态从Destroyed变更为Destroyed Compromised。

密钥的暂停和恢复​

当密钥处理Operational或者Post Operational阶段，出于某些安全考虑，在MPC-KMS中可以通过Disable操作临时禁止密钥使用或者通过Enable操作恢复以暂停密钥的使用。

系统通过IsEnable标记暂停和恢复状态。

密钥材料更新​

MPC-KMS定期通过更新操作对已有密钥的材料进行更新，以提高密钥的安全性。

密钥材料的更新不影响密钥的正常使用。

密钥权限管理​

密钥权限管理指在密钥整个生命周期中，用户进行各种操作时，MPC-KMS对用户操作进行的授权管理机制。只有当用户满足操作授权要求，才能执行相应的操作。操作包括密钥使用操作和密钥管理操作。

权限管理模型​

MPC-KMS的目标是使用最小权限集去满足用户密钥操作需求，目前的权限管理模型如下：

用户、角色和权限的创建和更新只能由MPC-KMS管理员进行操作。

用户User​

MPC-KMS密钥权限管理适用于两类操作用户：

  • 通过钱包直接登录MPC-KMS系统，通过MPC-KMS页面进行密钥操作的用户。
  • 通过AK/SK接入MPC-KMS系统，通过API接口进行密钥操作的用户。

角色Role​

MPC-KMS的角色可以在密钥和操作的粒度上实现最小特权原则，可以根据需求，指定一个角色，允许用一个特定的密钥进行特定的操作。

一个用户可以拥有多个角色，一个角色可以包含多个用户。。

权限Permission​

MPC-KMS的权限绑定一个密钥组和一组操作列表：

  • 密钥组：一组密钥的集合，一个密钥只能在一个密钥组中，密钥组内的密钥必须是同类的。
  • 操作列表：密钥组支持的操作集合，单个密钥组的单个操作只能绑定单个权限中。单个权限可以绑定多个操作。

密钥支持的操作列表​

管理操作

  • Create： 生成密钥。
  • Active： 激活创建的密钥。
  • Disable/Enable： 暂停和恢复密钥。
  • Revoke： 普通撤销密钥。
  • Compromise： 泄漏撤销密钥。
  • Destroy： 摧毁密钥。

使用操作

  • Sign：生成签名。

示例​

  • 创建一个TESTKEY_SIGNER角色，该角色只有一个权限：允许对密钥组TEST_GROUP内部的密钥进行签名操作。
Role: TESTKEY_SIGNER
    Permission:
    Key Group: TEST_GROUP
    Operations: Sign
  • 创建一个TESTKEY_MANAGER色，该角色只有一个权限：允许对密钥组TEST_GROUP内部的密钥进行管理操作。
Role: TESTKEY_MANAGER
    Permission:
    Key Group: TEST_GROUP
    Operations: Create、Active、Revoke、Compromise、Destroy、Enable、Disable
  • 创建一个TESTKEY_MIXED角色，改角色只有一个权限允许对密钥组TEST_GROUP内部的密钥进行管理和使用操作。如果上诉的TESTKEY_MANAGER或者TESTKEY_SIGNER角色存在，因为密钥组操作重叠，创建角色会失败。
Role: TESTKEY_MIXED
    Permission:
    Key Group: TEST_GROUP
    Operations: Sign、Create、Active、Revoke、Compromise、Destroy、Enable、Disable
  • 赋予用户TEST多个角色，允许其同时对密钥组TEST_GROUP进行管理操作和签名操作。
User: TEST
    Role: TESTKEY_MANAGER
    Role: TESTKEY_SIGNER

审批策略​

MPC-KMS的每个操作均可以配置与之相关的审批策略，确保操作安全可控。

法定人数审批组​

MPC-KMS使用法定人数审批机制。法定人数审批是指定义了一组审批用户，只有当其中最小的用户子集（即法定人数）批准了操作才能被执行。这种N个用户，至少M个用户批准模式也被称之为MofN。 比如，可以定义在审批组中设置8个用户，必须其中5个用户批准操作；也可以定义多个审批组审批，最小的5个审批用户其中3个用户来自A组，2个用户来自B组。

审批策略架构​

在MPC-KMS中，审批策略和权限绑定，在创建权限的时候设定，主要包括两部分：

  • 审批规则Rules：定义各种审批规则，比如API接口审批规则、审批时限等。
  • 审批用户组Approval Groups：法定人数审批组，每个审批组均需要设置法定人数。系统支持配置多个审批组。

主要审批规则​

使用接口审批规则

仅当当前操作为使用操作是有效

  • 强制审批：忽略API接口标记强制对密钥组的使用操作进行审批。
  • API定义：根据API接口标记决定是否对密钥组的使用操作进行审批。

审批时长

审批时长指等待所有审批组的完成审批最长时间。如果在指定的时间未完成审批，认为审批失败。

多法定人数审批组的审批​

系统支持多个法定人数审批组。如果配置了多个法定人数审批组，审批组的顺序决定了通知的顺序，只有一个审批组审批通过后才会通知下一个审批组。 比如密钥TEST_KEY归属密钥组TEST_GROUP，同时密钥组TEST_GROUP的Sign操作，配置了审批组APPROVAL_A和APPROVAL_B，APPROVAL_A排在APPROVAL_B的前面。那么TEST_KEY的Sign操作需要经过如下的审判流程：

  1. APPROVAL_A组内用户收到批准TEST_GROUP密钥组的Sign操作的请求。
  2. APPROVAL_A组用户陆续批准请求，并达到APPROVAL_A组设定的法定人数。
  3. APPROVAL_B组内用户收到批准TEST_GROUP密钥组的Sign操作的请求。
  4. APPROVAL_B组用户陆续批准请求，并达到APPROVAL_B组设定的法定人数。
  5. 执行TEST_KEY的Sign操作。